Summary

The count of a search (totalCount) stops at 1001. When a search has more than 1000 matches, the interface shows "1000+" and the database does not count further, so the cost of the count does not grow with the catalog.

Part of #110 (the one issue for making the whole Elements page work, in several pull requests). The page that shows "1000+" is in #120; this change is independent of it and goes to dev.

What is in it

• backend/src/catalog/search.ts: totalCount is count({ where, take: max + 1 }). MAX_TOTAL_COUNT is 1000, so a search with more matches gets 1001, which means "more than 1000". A search with 1000 or fewer matches is counted as before. maxTotalCount is an argument, so the tests can try a small limit on the catalog.
• backend/src/schema.graphql and docs/API.md: the schema is the same (Int!). The text says that the count stops at 1001 and that a value above 1000 means "more than 1000". The paragraph that said that a cap "needs a change in the schema" now says that it is done, and that it only needs a new meaning of a value above 1000.
• docs/AI_USAGE.md.

Testing

• npx vitest run: 37 files, 350 tests passed. New: 5 in search.test.ts (the catalog is smaller than the limit and is counted as it is, the count stops at one more than the most, it is not capped when the most is as big as the number of matches, a search is capped too, text with no searchable words counts 0).
• I removed take to check the tests: two of them fail without it.
• eslint and tsc -b pass.
• The catalog has 562 entries, so nothing is capped in the real catalog today. The cap is tested with a small limit.

Open points

• A client that has the old meaning of totalCount (the exact number) shows 1001 for a search with more than 1000 matches. The only client is the Elements page, which is changed in feat: make Load more elements fetch the next page #120.

🤖 Generated with Claude Code